The present invention generally relates to generating, backing up and restoring data, and more particularly to avoiding inode number conflict during metadata restoration.
In a hierarchical data storage system, data backup may include pre-migration of data to a backup medium (e.g., continuous copying of data from a disk to a tape). Metadata associated with the data may also be copied and used for restoration of the backed up data. Metadata may include information about a data file or directory, such as time and date of creation, creator/owner, file size, file tree information, etc. Certain metadata (e.g., owner of the file (UID), file size, etc.) for a file may be stored in a structure called an inode. Each inode may be assigned an ID called an inode number. Typically, each inode number is unique to the file system or partition containing the inode. The contents of the data file or directory associated with the inode may be stored elsewhere on a disk. In the case of data files physically stored on a backup tape, a table (e.g., a file-tape mapping table) may include inode numbers and the locations on the backup tape for the data files corresponding to the inode numbers. A directory entry may list inode numbers and corresponding filenames.
In one example of file restoration, backup tapes containing backed up data may be brought to a secondary site for restoration. In another example of file restoration, metadata associated with the backed up data (e.g., file tree information) may initially be written from a backup tape to a disk at the secondary site and, subsequently, backed up data (e.g., files) may be written from the tape to the disk when the backed up data is accessed/requested. In such examples, the inodes for the backed up data may be restored first and then the associated data may be written from the backup tapes (or other media) when needed.
In one example, a file system associated with a first location (e.g., a primary site) may assign inode numbers independently from a second file system associated with a second location (e.g., a disaster recovery site). A first file generated at the first location may be assigned an inode number that conflicts with the inode number assigned to a second file at the second location. Restoration of the inode associated with the first file may not occur at the second location because the inode number for the first file has already been allocated at the second location.